-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PROF-11078] Fix profiling not working when agent url is an ipv6 address #4252
Conversation
Steep doesn't seem to be a big fan of Structs so I just went ahead and turned the `AgentSettings` into a regular class that's equivalent to the struct we had before. (In particular, I decided to still keep every field as optional). Ideally this would be a `Data` class, but we're far from dropping support for Rubies that don't have it.
This is preparation to also share this behavior with profiling.
The behavior from the old `AgentBaseUrl` is now contained in `AgentSettings` so we can clean up the extra logic.
**What does this PR do?** This PR builds atop #4237 and fixes a similar-ish issue in the profiler caused by the same mishandling of ipv6 addresses. In particular, when provided with an ipv6 address in the agent url, the profiler would fail with an exception: ``` $ env DD_AGENT_HOST=2001:db8:1::2 DD_PROFILING_ENABLED=true \ bundle exec ddprofrb exec ruby -e "sleep 2" dd-trace-rb/lib/datadog/profiling/http_transport.rb:27:in `initialize': Failed to initialize transport: invalid authority (ArgumentError) ``` **Motivation:** Luckily we didn't have any customers using this, as it fails immediately and loudly, but it's still a bug on a configuration that should be supported. **Additional Notes:** Since we had similar buggy logic copy-pasted in crashtracking and profiling (crashtracking had been fixed in #4237) I chose to extract out the relevant logic into the `AgentSettings` class, so that both can reuse it. **How to test the change?** I've added unit test coverage for this issue to profiling, and the snippet above can be used to end-to-end test it's working fine. Here's how it looks on my machine now: ``` E, [2025-01-02T17:32:32.398756 #359317] ERROR -- datadog: [datadog] (dd-trace-rb/lib/datadog/profiling/http_transport.rb:68:in `export') Failed to report profiling data (agent: http://[2001:db8:1::2]:8126/): failed ddog_prof_Exporter_send: error trying to connect: tcp connect error: Network is unreachable (os error 101): tcp connect error: Network is unreachable (os error 101): Network is unreachable (os error 101) ``` E.g. we correctly try to connect to the dummy address, and fail :) (Note: The error message is a bit ugly AND repeats itself a bit. That's being tracked separately in DataDog/libdatadog#283 )
Forgot this one, some of our tests relied on it!
Datadog ReportBranch report: ✅ 0 Failed, 22115 Passed, 1475 Skipped, 5m 16.4s Total Time |
BenchmarksBenchmark execution time: 2025-01-03 09:27:16 Comparing candidate commit b7d24f6 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 31 metrics, 2 unstable metrics. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4252 +/- ##
==========================================
+ Coverage 97.74% 97.76% +0.01%
==========================================
Files 1355 1353 -2
Lines 82366 82353 -13
Branches 4230 4224 -6
==========================================
- Hits 80512 80509 -3
+ Misses 1854 1844 -10 ☔ View full report in Codecov by Sentry. |
What does this PR do?
This PR builds atop #4237 and fixes a similar-ish issue in the profiler caused by the same mishandling of ipv6 addresses.
In particular, when provided with an ipv6 address in the agent url, the profiler would fail with an exception:
Motivation:
Luckily we didn't have any customers using this, as it fails immediately and loudly, but it's still a bug on a configuration that should be supported.
Change log entry
Yes. Fix profiling not working when agent url is an ipv6 address
Additional Notes:
Since we had similar buggy logic copy-pasted in crashtracking and profiling (crashtracking had been fixed in #4237) I chose to extract out the relevant logic into the
AgentSettings
class, so that both can reuse it.How to test the change?
I've added unit test coverage for this issue to profiling, and the snippet above can be used to end-to-end test it's working fine.
Here's how it looks on my machine now:
E.g. we correctly try to connect to the dummy address, and fail :)
(Note: The error message is a bit ugly AND repeats itself a bit. That's being tracked separately in DataDog/libdatadog#283 )